M3 MacBook Pro 能提效？程序员、产品经理自证后，CTO：你赢了，新电脑在路上了

编译 | 苏宓

出品 | CSDN（ID：CSDNnews）

2023 年 10 月底，苹果公司用 30 分钟快速宣布了 M3 系列芯片及设备的到来，彼时库克形容道「它性能逆天、技术先进、能效非凡」。

新版本的发布，吸引了不少果粉的目光。而对于科技公司而言，在员工入职时给配备一台 MacBook 电脑其实也不足为奇。因此，在最新搭载 M3 系列芯片的 MacBook 开启售卖之后，不少员工想要作为首批体验用户能够用上，而国外一家专门提供处理紧急事件软件的开发商 incident.io 便是被员工追问是否购买新设备的公司之一。

在 incident.io 内网中，有不少员工表示：

• 哇，如果我的笔记本电脑看起来那么好，我的工作效率会提高多少？

• 如果我们的机器是深空黑的，也许我们会更安全🤔

面对员工热火朝天的讨论，该公司 CTO Pete 回应道，“如果能证明这是值得的，那么就会购买。”

此话一出，不少员工心动了。对此，在以 incident.io 产品经理 Lawrence Jones 为首的团队迅速展开了行动，其在程序员的帮助下，首先开发了一款自定义的 Go 热加载工具，并用此工具跟踪开发者笔记本电脑的遥测数据（从 MacBook 内各种来源和子系统收集数据的最终结果），将这些数据加载到 OpenAI 最新的 GPT-4 模型中，然后进行分析，最终帮助公司衡量是否应该放弃现有的 M1/M2 设备而花钱去购买最新的 M3 MacBook Pro 给程序员用。

接下来，我们将看看 Lawrence Jones 究竟是怎么做的！

程序员的工作难以量化

对于 Incident.io 以及业界很多团队而言，量化开发者的生产力是一件很难的事情，但是获得更快的反馈循环（feedback loop，通过识别问题、改进功能和验证设计选择来促进持续改进）可以有效提升开发者的效率。

在该公司内部，其本地开发中最常见的反馈循环是：

• 编译 Go monolith。

• 运行代码生成：API 客户端、接口等。

• 对前端/移动应用程序采用热加载技术（在不重启服务的情况下让更改的代码生效）。

所有开发者都在自己的笔记本电脑上使用完全成熟的 Incident.io 环境进行本地开发：它允许在更改代码和运行代码之间实现 <30 秒的反馈循环。

因此，编译 Go 应用程序是这些循环中最频繁也是最昂贵的步骤之一，代码库拥有接近 100 万行的代码。作为这些任务中最耗费资源的一项（就系统资源而言），倘若拥有更强大的硬件可能会更好。

基于此，Incident.io 团队选择 Go 编译速度作为衡量 MacBook 性能的关键指标：现在该团队只需要测量它。

获取遥测数据

据 Lawrence Jones 介绍，一直以来 incident.io 都是使用 codegangsta/gin（https://github.com/codegangsta/gin）作为 Go 程序的热加载工具。它运行良好，每当代码文件发生变化时，它就会编译并重启新版本的应用程序。不过，由于遇到一些难以解决的原因，incident.io 不得不考虑更换一种工具。

然而，当 Lawrence Jones 等人查看其他热加载工具时，没有发现任何一款热加载器可以提供给他们想要的跟踪编译程序时间获取遥测数据（从 MacBook 内各种来源和子系统收集数据的最终结果）。

对于 Lawrence Jones 而言，其理想中的热加载工具可以获得：

• 系统尺寸：平台（M1/M2/M3）、总内存等。

• 运行时指标：操作系统、内存使用情况、电源、电池电量等。

• 遥测数据：总持续时间、Go 编译阶段、哪些文件触发了构建等。

由于没有现成的替代方案，Lawrence Jones 决定构建自己的替代方案，以便根据其具体的需求进行定制。

本次实验的主要动机是获取遥测数据，因此这一过程一开始只是一个简单的 main.go，Lawrence Jones 和他的程序员同事对其进行了调整，直到它可以从主机中提取上文所需的内容。

其实 Mac 电脑有许多二进制文件可以帮助你完成此操作，如 memory_pressure、docker、sysctl 和 pmset，而代码主要是执行和解析它们的输出：

memoryFreeRegex := regexp.
  MustCompile(`^System-wide memory free percentage:\s+(\d+)%`)

// Run memory_pressure...
memoryPressure, _ := exec.Command("memory_pressure").Output()
for _, line := range strings.Split(string(memoryPressure), "\n") {
    if memoryFreeRegex.MatchString(line) {
        // ...parse result!
        ev.MemoryFree = memoryFreeRegex.FindStringSubmatch(line)[1]
    }
}

一旦成功构建了系统和运行时收集器，封装 Go 编译命令就很简单了，这样就可以提取 bulid 的特定指标，如阶段时间（链接器、编译等），并跟踪哪些文件导致触发了 build。

最终，Lawrence Jones 从现有的 make run 目标运行热加载程序。

“这对我们的工程团队来说是个无形的改变，但却意味着，现在每次构建完成后，我们都会向自己选择的 HTTP 端点发送遥测事件。我们设置了一个 Fivetran Webhook 端点接收器（incident.io 内部的 ETL 工具），它可以将事件推送到我们的数据仓库，仅此而已！”Lawrence Jones 说道。

最后，Lawrence Jones 获得了判断 Mac 性能所需的数据。

分析数据

根据上述步骤，Lawrence Jones 等人等待了几周之后收集到了足够大的数据集，紧接着，也就是进入了分析数据阶段。

不过，大多数开发人员都知道，即使在同一系统上，编译时间也是千变万化的。Go 编译器尤其会对编译过程进行大量缓存，因此即使是最强大的 M3，在没有缓存的情况下编译速度也要比有缓存的老式 Intel 版本的 MacBook 慢得多。

这意味 Lawrence Jones 不能直接比较不同平台的平均构建时间。

相反，他们需要真正深入挖掘底层数据，这提供了一个使用 OpenAI GPT-4 最新代码解释器的绝佳机会。

创建 OpenAI 助手

在使用 GPT-4 分析数据时，Lawrence Jones 分享了具体的流程：

• 将数据导出为 CSV：使用 BigQuery 导出了 select * except(payload) from developer__build_events 的结果。

• 创建一个"助手"，用提示词帮助解释实验的目的，并向其提供包含数据的 CSV 文件。

详细来看，Lawrence Jones 使用了实验性的 gpt-4-1106-preview 模型，并启用代码解释器来进行数据分析。只用了几分钟，助手便搭建好了，一切准备就绪后，它开始回答相关的数据分析问题。

清洗数据

此次 Lawrence Jones 一共收集到了 25k 条数据，所有数据是在一天中的所有时间、各种笔记本电脑和许多不同的条件下获得的。

为了在平台之间进行良好的比较，也希望为这些编译建立尽可能公平的比较，Lawrence Jones 删除了具有混杂因素的数据。

• 失败或取消的编译数据：如果有人在编译完成之前退出，这相当于是一个半成品，需要剔除这些数据。

• 使用电池供电：OS X 会限制性能以延长电池寿命。

接下来，让我们了解一下有多少编译是不成功的，以及每个平台有多少编译活动。

向 GPT-4 提问：

向我展示按机器平台分列的构建分布情况，其中平台按 M1 至 M3 排序，在平台类中 Pro 位于 Max 之前。

按编译成功（退出状态为 0 且未取消）与失败对每个平台的构建次数进行拆分。

我是一个视觉学习者，我希望看到这样的结果：我们按 M1 至 M3 对平台进行排序，在每个平台类别中，Pro 排序在 Max 之前。

也许这样和 AI 聊天机器人对话感觉很奇怪，但它给出了我们想要的：

可以继续对 GPT-4 说：

从现在开始，请从数据集中排除失败的编译。

当机器人说已从数据集中剔除了失败的编译。现在可以处理包含 12,525 个成功编译的数据集。

假设使用电池供电的机器会受到限制，导致构建时间不能很好地代表总体性能。Lawrence Jones 也想通过比较不同电源的同一平台的性能来确认这一点。

于是，他又问道：

仅关注 Apple M1 Pro 和 Apple M2 Max 平台的成功编译，您能否直观地比较不同电源的构建持续时间？

最终得到如下结果：

结果显示，交流电通常更快。

继续向 GPT-4 求解：

在你看来，使用交流电源还是电池电源会影响编译性能吗？

机器人回应道：

我将计算成功构建数据集的 t 检验并报告 p 值。低 p 值（通常小于 0.05）表明交流电源和电池电源在构建性能方面存在显著差异。

...

负 t 统计量表明，交流电源的平均构建持续时间低于电池电源。此外，P 值约为 0.0014，远低于 0.05 的常用临界值，我们有足够的证据来拒绝零假设。

鉴于这一统计检验的结果，我们可以得出结论：使用交流电源还是电池电源确实会影响所有平台的构建性能，使用交流电源的构建往往比使用电池电源的构建更快。

Lawrence Jones 表示，「这就说明了问题：从现在起，我们将只考虑成功编译+使用交流电源的电脑！」

比较 M1 和 M2

当 Lawrence Jones 进一步向 GPT-4 提问：

仅关注 M1 Pro 和 M2 Max（因为这些是我们拥有最多数据的平台），您可以绘制两个直方图来显示成功的构建持续时间，并消除极端异常值。

总体而言，从下图可以很明显看出 M2 Max 在构建速度方面完全远超 M1 Pro。

不过，也需要注意的是，这些 MacBook 的不同之处不仅仅是芯片组，还有内存：

您能告诉我构建事件如何按机器平台和内存配置划分吗？

GPT-4：

以下是每个平台内每种内存配置的成功构建事件数：

• Apple M1 Pro  （16GB）：5,235 次构建事件

• Apple M2 Pro  （16GB）：1,927 次构建事件

• Apple M2 Max  （32GB）：3,842 次构建事件

• Apple M3 Pro  18GB：321 次构建事件

• Apple M3 Pro  （36GB）：899 次构建事件

• Apple M3 Max  （36GB）：301 次构建事件

Lawrence Jones 表示，“我们的 M1 Pro 和 M2 Max 之间的比较有些不公平，因为 M2 均具有 32GB 内存，是 M1（16GB）的两倍。”

这可能就是性能如此不同的原因（尽管声称 Apple 电脑需要很少的 RAM），并且在决定是否应该升级到什么规格的 M3 时会很有用。

值得庆幸的是，数据集中有来自具有 16GB 内存的 M2 Pro 的 2k 构建事件，所以 Lawrence Jones 继续问 GPT-4：

您能否重新绘制 Apple M2 Pro 16GB 和 Apple M2 Max 32GB 标准化构建持续时间的直方图比较？

最终得到如下结果：

要知道 M2 Pro 和 M2 Max 基本上是相同的芯片，主要区别在于 Max 具有两个额外的“节能”核心。这些核心的功能大约是性能核心的 1/5，并且对编译 Go 程序的贡献最小，因此对我们的构建持续时间也有最小的贡献。

那么，这种比较是非常有用的：它意味着 32GB 的影响很小，也许只是有助于快速构建时间的更高密度，但总体而言不是很明显。

比较 M3 的不同版本

从目前的情况来看，内存容量为 16GB 的 M2 Pro 似乎性价比最高，速度几乎是 M1 的两倍，比 M2 Max 稍慢（即使 Max 的内存容量是 M1 的两倍）。

现在，我们需要弄清楚 M3 与 M2 相比是否有明显的改进，为此，Lawrence Jones  也购买了一些新的笔记本：

M3 Pro，12 核（6 个性能核，6 个能效核）

• 1 个 18GB 内存

• 1 个 36GB 内存

M3 Max，14 核（10 个性能内核，4个能效核）

• 1 个 36GB

总共三台笔记本电脑，Pro 的内存有所不同，而购买 Max 则是为了测量我们是否能看到额外的 4 个 P 核心有多大差别。

如果从 Pro 开始：

向我展示 M3 Pro 18GB 和 M3 Pro 36GB 的构建持续时间柱状图。

之前得出的结论是，内存对构建性能的影响不大，因此这些图表看起来相似也就不足为奇了。

事实上，由于缺乏数据，M3 的构建次数远远少于其他平台。基于此，Lawrence Jones 将两个 M3 Pro 的结果合并起来：

向我展示 M3 Pro 18GB 和 36GB 组合与 M3 Max 的构建持续时间直方图，去除非常快的构建时间（<3 秒）。

同样，在这里遇到的数据要少得多，但即便如此，M3 Max 看起来并没有比已经很快的 M3 Pro 做出任何真正出色的事情。

至少，不足以证明比基础版 M3 Pro 涨价 60% 是合理的。

M1、M2、M3 一起比较

到目前为止，Lawrence Jones 表示：

• 已经建立了 M1 机器的基准线。

• 确定 M2 机器的性能相当，与内存或附加内核无关。

• M3 在 Pro 和 Max 上也相似。

那么，接下来，是时候全面了解这些平台的比较了……

向我展示比较所有平台和内存组合的构建持续时间直方图，不包括在 <3 秒内完成的构建。

请重复上述操作，但每行使用一个直方图，并将 M1、M2 和 M3 平台合并。

这清楚地表明：

• 使用 M1 笔记本电脑的用户经常需要等待近 2 米才能完成构建。

• M2 是 M1 机器的重大升级。

• M3 是 M2 的渐进式改进。

建议：

• 我们应该将所有 M1 用户升级到基本的 M3 Pro 机型。

• M2 用户不需要升级。

完毕！

One More Thing

通过以上对不同内存的电脑进行比较，Lawrence Jones 坦言，从测试的构建持续时间上来看，看不到从 ~16GB → 32GB 的有意义的改进。

那么内存大小对程序开发是否会带来影响？

作为开发者其实不难理解，有时候构建耗时比较长的原因在于链接器上。在链接器中，编译后的 Go 包被连接在一起形成一个可执行二进制文件。

为了测试，Lawrence Jones 提问道：

在我们的数据集中有一个 build_stages 列。我们可以在数据集中添加一个新列，称为“linker_time”，它源自 build_stages.link.duration_seconds。

GPT-4：

该 linker_time 列已成功添加到数据集中。新列反映了从 build_stages 列内的 JSON 结构中提取的 linker 阶段（link.duration_seconds）的持续时间，单位为秒。

这很好理解，遥测事件包含链接/编译的持续时间，因此 Lawrence Jones 可以告诉 GPT-4 在构建事件中新建一列 linker_time：

请按照之前指定的顺序绘制每个平台和内存组合的 linker_time 直方图，并根据机器内存是 16-18GB 还是 32-36GB 给每个直方图涂上不同的颜色。

这看起来完全不同！也就是说，每台内存大于 30GB 的电脑（M1、M2 或 M3）几乎都能在 20 秒内完成链接，只有内存小于或等于 18GB 的机器才会在 >20秒内完成链接。

所有这一切都意味着，只需象征性地增加内存成本，就推荐购买 36GB 的内存，即使你认为这只是“为未来做准备”。

CTO：M3 已经在路上了！

根据以上测试，无可辩驳，新款深空黑色的 M3 Pro 笔记本电脑不仅在外观上看起来“倍有面”，而且还可以提高程序员的效率，缩短交付时间。

对于这样的测试结果，Incident.io CTO Pete 现身在内网上也迅速回复道：“好吧好吧你赢了！这是我听过为了升级电脑而展开的最好论点，以及也亲证了一个真正令人印象深刻和愉快的书面报告。不过，基于这些数据，我显然预计到 2024 年，大家的生产率会相应提高 10%。”

具体来说，该公司决定将其 M1 版电脑升级到具有 36GB 统一内存的基础款 M3 Pro，但现在使用 M2 的程序还需要再等待一段时间，因为 M2 的性能表现得也不错。

原文地址：https://incident.io/blog/festive-macbooks

推荐阅读：